home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
172anew.zip
/
UPTEST.DOC
< prev
next >
Wrap
Text File
|
1989-05-23
|
2KB
|
56 lines
Documentation for Upload Testing for RBBS 17.2A
by Ken Goosens
24 May 1989
RBBS, in the drive/path where command.com is, now looks for a file
called T<ext>.BAT, when <ext> is extension of file uploaded.
If found, RBBS will shell to this processing. This allows the sysop
to install whatever processing desired after an upload. The main
application is to test the upload for integrity, but any processing
desired is possible.
If the BAT file contains exactly 1 line, RBBS will shell not to
the BAT file but to the contents of the bat file, after substituting
the name of the file upload for "[1]" and the name of the file to
write the results to for "[2]". If the BAT file contains more than
one line, RBBS will shell to the BAT file itself, passing file to
test as 1st parmeter and file to write out results of test as 2nd.
The upload will be treated as BAD, and deleted, if the result file
has a length greater than 2 bytes. The BAT file should either not
write a result file or an empty one if the upload is okay; otherwise
write out some error message more than 2 bytes long.
One way to do this is to run a test of the compression and pipe the
results to a text scanner than looks for an error string and redirects the
output to a file if an error is found. For example, the file VARC.BAT
PKXARC -T [1] | FGREP "error in a" > [2]
works. Another possibility is
ARCE [1] /T/P | FGREP "Invalid a" > [2]
Note: both PKXARC and ARCE set the errorlevel above 0 if the arc
is bad. An alternative implementation is:
PKXARC -T %1
IF ERRORLEVEL 1 ECHO BAD UPLOAD > %2
SETERROR 0
or
ARCE %1 /T
IF ERRORLEVEL 1 ECHO BAD UPLOAD > %2
SETERROR 0
Under versions of Quick Basic prior to 4.5, programs that
reset the error level cause illegal function call 5 upon return from
the shell. Therefore it is necessary to run a utility to reset the
error level back to 0 before going back to RBBS. This is what the
SETERROR.EXE file does.
The recommended procedure is to use PKXARC, check errorlevel, and
reset errorlevel to 0. PKXARC runs faster, ARCE will hang on certain
invalid ARC files, and, finally, both ARCE and PKXARC put out somewhat
variable strings when different errors occur, making a filter based
on text more difficult to implement.